[レポート] #API307 Amazon EventBridge を使用したイベント駆動型統合の設計 #reinvent

AWS re:Invent 2022

#Amazon EventBridge

#AWS

川崎照夫

2023.03.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

アノテーションテクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

イベントドリブンアーキテクチャは、組織のビジネス機能に整合性をもたらすことができます。 Amazon EventBridge は、ビジネスアプリケーション間のアプリケーション統合を可能にし、最新のアプリケーション開発プラクティスを改善します。このセッションでは、利害関係者グループの役割と責任について学び、組織のために持続可能でスケーラブルなサーバーレスイベントバスを設計および構築するための基本的な概念を発見します。

セッション動画

アジェンダ

マルチアカウントトポロジについて学んだこと
カップリングとイベント
イベント駆動型アーキテクチャにおける役割と責任
Amazon EventBridge を使用して、サーバーレスのイベント駆動型イベントバスを設計する

このプレゼンテーションでは、Eventbridge を使用したイベント駆動型アーキテクチャの設計の基礎について説明します。組織全体での採用を計画する際に行う必要がある重要な設計上の決定について説明します。プロデューサーとコンシューマーが持つ役割と責任、およびそれらが Eventbridge とどのように関係しているかを理解することが強調されています。また、手元のアーキテクチャに適切なイベントを使用すること、および分散システムでのカップリングのコアを理解することの重要性も強調しています。最後に、Eventbridge を使用したサービス統合の設計に関する考えを共有します。

過去のセッション「Amazon EventBridge を使用したイベント駆動型アーキテクチャの構築」

マルチアカウントトポロジについて学んだこと

どのトポロジを選択すればよいですか?

1 つのアカウントで 1 つのイベントバス？
1 つのアカウントで複数のイベントバス？
単一のイベントバス、複数のアカウント？
複数のアカウントにまたがる複数のイベントバス？

シングルバス、マルチアカウントパターン

特徴
- すべてのサービスは、単一または「中央」のイベントバスにイベントをプッシュします。
- すべてのサービスのルールは、中央のイベントバスで作成されます。
チーム
- DevOps チームがアクセスポリシーを管理し、リソース管理をチームに委任します
- サービスチームは DevOps チームと協力してリソースのニーズを調整します
考慮事項
- 追加のクロスアカウントポリシー管理。ここでリソースポリシーが役立ちます。
- 開発速度への潜在的な影響を考慮する

マルチバス、マルチアカウントパターン

特徴
- サービスは、所有および管理するイベントバスにイベントを発行します。
- サービスが公開しているイベントにサブスクライブしているサービスからのルールのみを含む
チーム
- サービスチームは、サービスイベントバスと、イベントを送受信するためのすべてのリソースを管理します。
考慮事項
- 分散ルールを管理する際の追加のオーバーヘッド

マルチアカウントバストポロジの比較

RESOURCE DISTRIBUTION

シングルバストポロジ
- 一元化された
マルチバストポロジ
- 分散型

統合ロジックからルーティングロジックを分離することで、イベントの受信方法に影響を与えずに統合を追加または削除できます。このパターンを使用すると、開発チームは、構築中のアプリケーションのイベントを配布する手段を手に入れ、それらのアプリケーションをより簡単に管理できるようになります。管理する必要のあるリソースの数はそれほど多くなく、アプリケーションを構築するための非常に自然な方法のように思えます。

マルチアカウントバストポロジの比較

RESOURCE MANAGEMENT

シングルバストポロジ
- 集中 (n+1)
マルチバストポロジ
- 分散型

マルチアカウントバストポロジの比較

RESOURCE MANAGEMENT

シングルバストポロジ
- 集中 (n+1)
マルチバストポロジ
- 分散型

マルチアカウントバストポロジの比較

RULE DISTRIBUTION

シングルバストポロジルールの配布
マルチバスルールの配布

ルールは両方のケースで配布されますが、方法が異なるだけです

マルチアカウントバストポロジの比較

RULE DISTRIBUTION

シングルバストポロジルールの配布
マルチバスルールの配布

ルールは両方のケースで配布されますが、方法が異なるだけです

マルチアカウントバストポロジの比較

DISTRIBUTION OF SERVICE LIMITS

シングルバスルール制限の配布
- 中央イベントバスのすべてのサブスクリプションルールに制限が適用されます
マルチバスルール制限の配布
- 特定のドメインのサブスクリプションルールに制限が適用されます

ルールの増大への対処

DISTRIBUTION OF SERVICE LIMITS

中央アカウントの複数のイベントバスにドメインを分散
論理ドメイングループは、指定されたイベントバスに発行できます。
消費者は、イベントが公開される場所を認識する必要があります
バスポリシーでは、イベントコンシューマーが中央のイベントバスにルールを設定できるようにする必要があります。

ルールの増大への対処

DISTRIBUTION OF SERVICE LIMITS

Amazon EventBridge は、組織内のあらゆるタイプのトポロジーに使用および適応できる、非常にスケーラブルなサーバーレスソリューションです。イベントバスでルールを作成するサービスによって、適切なポリシーが保証される必要があります。アプリケーションをクラウドに移行することで、組織は毎秒数万のイベントを処理し、それらをグローバルに配信できます。

マルチアカウントバストポロジの比較

WHICH IS BEST?

シングルバストポロジ
マルチバストポロジ

場合によります！！！

1 行のコードで何ができるでしょうか?

aws events create-event-bus --name MyDomainEventBus

非独占的なプロトコルとツールを使用した強力で軽量な統合サービス
毎秒数十万のメッセージをルーティングする機能
集中型または分散型のルーティングトポロジを作成する
アカウントや地域全体でイベントを送信および複製する
管理するインフラがない

カップリングとイベント

カップリング

カップリングの多くの側面

テクノロジーへの依存: Java と C++ の比較
場所の依存性: IP アドレス、DNS
データ形式の依存関係: Binary、XML、JSON、ProtoBuf、Avro
データ型の依存関係: int16、int32、string、UTF-8、null、empty
セマンティックな依存関係: 名前、ミドルネーム、ZIP
一時的な依存関係: 同期、非同期
インタラクションスタイルの依存関係: メッセージング、RPC、クエリスタイル (GraphQL)
会話の依存関係: ページネーション、キャッシング、再試行

出典: EnterpriseIntegrationPatterns.com

結合の適切なレベルは、エンドポイントに対する制御のレベルによって異なります。
グレゴール・ホープ
エンタープライズ統合パターンより

イベント

名詞

システムの状態が変化したというシグナル
不変オブジェクト
システム統合契約

イベントの種類

通知イベント
- 何か重要なことが起こったことを通知する
- 最小限の情報
- 詳細についてはプロデューサーに問い合わせる必要がある場合があります
イベントを運ぶ状態転送イベント
- データの変更を公開する
- 追加の詳細について生産者に問い合わせる必要はありません
- 例: Amazon DynamoDB ストリーム
- 直接的な依存関係のないドメイン間でデータを複製するのに便利
ドメインイベント
- 通知イベントと状態転送イベントの組み合わせ
- ビジネスドメインにできるだけ近いモデル
- ステートレスで不変の信頼できる情報源

出典: https://martinfowler.com/articles/201701-event-driven.html

ここでは、ソフトウェアアーキテクチャにおけるイベントの重要性について説明し、Martin Fowler によって定義された 3 つのタイプのイベント (通知イベント、ドメインイベント、およびイベント伝達状態転送イベント) について説明しています。通知イベントは通常、何か重要なことが発生したことを示しますが、通常は情報やコンテキストが欠落しているため、サブスクライバーは別のシステムにクエリを実行して詳細情報を取得する必要があります。イベントキャリングステートトランスファーイベントは、外部ソースにクエリを実行することなく、ローカルステートをさまざまなサービスに分散するのに役立ちます。ドメインイベントは、情報の変化を表現し、自己完結型のイベントです。

Amazon EventBridge イベント

コンシューマに提供するデータにコンテキストが追加されます
詳細タイプおよびソーススコープのイベントを境界付けられたコンテキストにフィールド化します。一緒に、イベントの意図とその詳細を説明します
異種システムとアプリケーション間の同種統合を確立するためのコア

イベント駆動型アーキテクチャにおける役割と責任

役割と責任

パブリッシュ/サブスクライブ統合パターン

パブリッシュサブスクライブ
- 特定のドメインイベントに対して 1 つの論理パブリッシャー、1 つ以上のコンシューマー
- 境界付けられたコンテキスト間に一貫した境界を適用します
- 複数のタイプのカップリングに対応 – 時間的、空間的、プラットフォーム

パブリッシュ/サブスクライブ統合パターン

契約の成立
- すべてのカップリングが除去されたわけではありません – 良好なカップリングがまだ残っています
- ビジネスコンテキストは、生産者と消費者の間の「契約」を確立します。
- 連絡先は EventBridge スキーマとして表すことができます

システムの境界を越えた一貫性は、イベントを定義する上で重要です。イベントが変更された場合、新しいコントラクトを確立する必要があります。これは、コンシューマーがそれらのイベントに新しい実装を提供する必要があることも意味します。プロデューサーは、同じイベントのバージョン 2 をまだ実装していないプロデューサーに下位互換性を提供しながら、コンシューマーをサポートするために、同じイベントの 2 つのバージョンを同時に発行する必要がある場合があります。基本的に、同じスペースに同じイベントの 2 つのバージョンを同時に存在させることはできません。プロデューサーは、誰がどのようにイベントを処理しているかを考慮せずに、できるだけリアルタイムに近いイベントを送信する必要があります。プロデューサは、イベントが誰またはどのように消費されているか、またはイベントが消費されているかどうかについて、まったく想定していません。

プロデューサーの責任

生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネスプロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています

プロデューサーの責任

生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネスプロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています

これは、イベント定義が進化するにつれて後方互換性を確保することも意味します

プロデューサーの責任

生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネスプロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています
- メッセージの配信は、イベントのコンシューマーのニーズとは関係なく、可能な限りリアルタイムに近い形で行われます。

プロデューサーの責任

プロデューサーは責任を負いません
- 消費者がイベントをどのように使用しているか
- コンシューマーの制約 (例えば、イベントがコンシューマーによって処理される速度) を知る
- コンシューマーがイベントを処理する前にどのように変換する必要があるかを理解する

消費者の責任

消費者の責任
- 受け取りたいイベントを指定する。さらに、選択的フィルタリングを介して
- イベントを処理する速度を決定する。たとえば、受信イベント速度 > コンシューマの処理能力
- 変革の必要性を判断する

誰が何を所有していますか？

イベントバスにイベントを公開できるユーザー
イベントバスでルールを作成できるユーザー
パターン
ターゲット
変換
DLQ
外部 API は、接続と API 宛先構成を定義します

外部関係者はイベントバスでリソースを作成できません。つまり、イベントバスの所有者は、外部の API 所有者と連携して、セキュリティ資格情報とエンドポイントの構成が変更されても統合が最新の状態に保たれるようにする責任があります。責任を適切に委任するには、リソースの明確な所有権を確立する必要があります。

Amazon EventBridge を使用して、サーバーレスのイベント駆動型イベントバスを設計する

Amazon EventBridge を使用したサーバーレスのイベント駆動型統合の基礎

イベント駆動型の統合 – マインドマップ

サーバーレスのイベント駆動型統合基盤
- イベント
  - ソース
  - 詳細タイプ
  - 資力
  - 詳細
- プロデューサー
  - ポリシー
  - スキーマ
  - 暗号化
  - カスタムフレームワーク
- 消費者
  - ターゲット
  - ポリシー
  - 検証
  - ルール
- ガバナンス
  - 可観測性
  - 信頼性
  - 組織のポリシー
  - 修復
- 発見
  - バージョン管理
  - スキーママッピング
  - 自動化/DevOps
  - セルフサービスプロビジョニング

イベント

イベントを一意に識別するには、一貫性が重要です。運用上のメリット
明確に定義されたドメインに合わせた命名規則を確立する
さまざまなイベントタイプを定義する方法について考えることに時間を費やす
イベントに追加のコンテキストを追加するカスタムメタデータを定義する

生産者

セマンティックの一貫性を強制することにより、イベントの整合性を確保します。
機密情報の暗号化はクライアントレベルで行う必要があります – 共有秘密は、消費者との間で確立された契約の一部です。
メタデータプロパティでイベントを初期化し、入力を検証するカスタムユーティリティの構築を検討する
複数のランタイムを通じて組織全体で標準化

EventBridge では、メタデータフィールドをイベントに追加して、追加のコンテキスト情報を提供できます。これは、メタデータ作成プロセスを抽象化し、開発チーム間で共有する再利用可能なライブラリとユーティリティを作成することで実現できます。統合チームは、このタイプのユーティリティをサポートし、プライベートパッケージリポジトリを通じて配布することで、組織全体で共有することを検討できます。ドメイン内のすべてのイベントのメタデータをモデル化することは、実際には意味がなく、構築されているドメインを反映しません。

独自のメッセージングユーティリティを構築する

開発チームが独自のソリューションを実装して、イベントペイロードにメタデータを含めることを避ける
イベントの一貫性と構造を強化できるユーティリティライブラリを作成する
組織が使用するランタイムをサポートする
使いやすいプライベートアーティファクトリポジトリを介して配布する

C# でのメッセージングユーティリティの例

プロデューサーは、イベントの詳細を表す CustomerMadePreferred クラスを定義します。
イベントは、ビジネスドメインを反映するようにモデル化されています。
メタデータを含まない

統合のニーズからドメインロジックを分離する

C# でのメッセージングユーティリティの例

ユーティリティライブラリは、実装を介して任意のイベントクラスを公開するための汎用インターフェイス IPublishEvents を定義します。

C# でのメッセージングユーティリティの例

Detail クラスもジェネリックで、Metadata プロパティが含まれています。 Metadata クラスは構造を定義し、IPublishEvents 実装を介して送信されるすべてのイベントのプロパティを初期化します

C# でのメッセージングユーティリティの例

最後に、インターフェイス IPublishEvents の実装により、AWS SDK を介してイベントが送信されます。
PublishEvent メソッドは、CustomerMadePreferred イベントパラメータを受け取り、シリアル化されて新しい PutEventsRequestEntry の構築に使用される新しい Detail オブジェクトを作成します。

独自のメッセージングユーティリティを構築する

メタデータの挿入をやめるのはなぜですか?
- 検証を追加する (公開されたスキーマに対して)
- 永続的なパブリッシャー – エラーを適切に処理し、イベントが「最終的に」確実に配信されるようにします。
- 複数のバージョンのイベントを配信するメカニズム
- 命名規則を強制する
- 配信前にイベントのサイズを検証する

機密データの操作

イベント内の個人を特定できる情報には暗号化が必要です
Amazon EventBridge は、転送中および保存中のイベントをすでに保護していますが、これはポイントツーポイントのみです。
暗号化はどこに適用されますか。
ミドルウェアで処理するか。責任をサービスに任せますか?

機密データの操作

ENCRYPTED PAYLOAD

パブリッシャーは、機密フィールドをイベントで送信する前に暗号化し、サブスクライバーがペイロードを復号化できるように暗号化キーにアクセスできるようにする責任があります。イベントが消費されると、イベントコンシューマは同じキーを使用して、別のイベントを通じてその情報を再送信できなくなります。暗号化キーは、パブリッシャーとサブスクライバー間の契約の延長を形成するものであり、そのように扱われるべきです。

機密データの操作

KMS CMK を明示的に共有して「契約」を延長する
コンシューマが管理するキーでデータを再暗号化する

機密データの操作

自問してみてください: 機密データの共有は絶対に必要ですか?
- 複数のドメイン境界にまたがる機密情報の複製
- 機密情報の管理は、複数の関係者の責任になります。
- ドメインの境界に注意してください。データの所有者は誰ですか? 正しくモデリングしましたか？

消費者

自己記述的なルール名を作成する
取り込み率を計画する – プロデューサーがイベントを発行する速度を制御することはできません
イベントを検証する必要がある場合は、公開されたスキーマを使用し、ローカルにキャッシュします
失敗に備える！これには再試行が含まれます。消費者を冪等にする

イベントバスルールの命名規則

ルール名は一意である必要があります。このための戦略がない場合、展開は失敗します
運用はルールのタグ付けで支援できますが、Amazon CloudFormation や AWS CDK を使用してルールタグを設定することはできないため、現時点ではこれの価値は限られています。
組織が採用する命名規則を設計する
ルールだけでなく、イベントバス、ターゲット名なども。これらをさまざまな環境 (開発、テスト、本番) に展開することに注意してください。

イベントバスルールの命名規則

イベントを購読しているのは誰ですか
どのターゲットが呼び出されているか
イベントはどこから来たのか
イベントの名前は何ですか

加入者ドメイン + ターゲット + イベントソース + 詳細タイプ com.marketing.CmpHandlerFunction-com.sales.CustomerMadePreferred (ルール名の最大 64 文字制限)

イベントの一意性

冪等性
- 操作は、1 回呼び出されても複数回呼び出されても同じ結果を返します (EIP)
冪等キー
- 送信者がメッセージに割り当てて、受信者による重複排除を簡素化

冪等性は、コンシューマーがメッセージを 2 回処理しないようにするために不可欠です。これにより、意図しない結果が生じる可能性があります。冪等性を実現する一般的な方法は、冪等性キーを定義することです。上記の例では、イベント ID を冪等キーとして使用できます。冪等性状態は、外部データストアで追跡できます。 AWS Lambda Power Tools for Python は、この目的に使用できるユーティリティです。このユーティリティは、冪等キーを持つイベントを受信したという事実を記録し、それを外部データストアに格納し、イベントを処理して、応答が送信される前に応答が保持されるようにします。

イベントの重複排除戦略

外部データストアでべき等状態を管理する
重複排除の時間枠を指定する
AWS Lambda Powertools Python べき等性ライブラリ
べき等 API で再試行を安全にする (AWS Builders' Library)

(Lambda Powertools Python べき等性、https://s12d.com/powertools-py-idempotency)

EventBridge の観点からの冪等性

冪等性ウィンドウはユースケースによって異なる場合があります

実行時 (べき等ウィンドウ 5 分)
イベントの再生 (べき等ウィンドウ > 5 分) イベント

EventBridge の観点からの冪等性

メッセージを複数回処理することを常に想定してください。
パーティションはネットワーク上だけでなく、データベースレイヤーやディスク IO でも発生します。
重複排除と順序付けは保証ではありません – それらは役に立ちますが、複数回処理されるイベントの処理方法に関する答えを得るために、ビジネスプロセスを確認することを忘れないでください。
システムの重要な部分にべき等制御を適用する – 重複を処理する方が簡単な場合があります。

ガバナンス

AWS Lambda Powertools (Python、Java、TypeScript、.NET) などのユーティリティライブラリを活用し、トレースのベストプラクティスを適用します。ロギングとメトリクス
EventBridge は AWS X-Ray トレース伝播をサポートしており、リクエストが流れているときにキャプチャすることができます異なるスタック間でイベントバスを介して
AWS CloudTrail によるリソース管理の監査 – これは自動化して、会社の基準の違反を是正することができます

AWS Lambda パワーツールを使用すると、サーバーレスコンピューティングからベストプラクティスを簡単に取り入れて、開発チームに組み込むことができます。ロギング、メトリクス、トレーサビリティ、および eventbridge の X 線サポートのためのツールを使用すると、アーキテクチャの健全性についてさらに洞察を得ることができます。 AWS cloudtrail などのサービスを使用して、自動化を構築し、組織内で確立されたルールと基準を適用できます。スキーマレジストリにはスキーマなどの既存の機能がありますが、イベントの検出、カタログ化、および組織全体で使用するためのイベントの記述には、まだやるべきことがたくさんあります。

発見

スキーマは、イベントの構造を記述する上で重要な役割を果たします
サービスの関係を伝え、理解するのに役立ちます
明示的な連絡先は、依存関係グラフを作成して、システムの境界を越えた一貫性を確保するのに役立ちます
このスペースでできることは他にもたくさんあります

オープンソースプロジェクト – イベントカタログ

特徴
- Amazon EventBridge のスキーマ、ターゲット、およびルールをドキュメントに変換します
- イベント、サービス、スキーマ、コード例などを文書化してキャプチャします
- ビジュアライザーを使用すると、すべてのイベント、パブリッシャー、およびサブスクライバー間の関係を確認できます
- David Boyne @boyney123 によるオープンソース

重要ポイント (Key takeaways)

カップリングを真剣に考えよう！分散型イベント駆動型システムを構築している – トレードオフがあります
適切なタイプのイベントを選択する – イベントのモデル化に時間を費やす
プロデューサーのニーズと責任、およびイベントの消費方法に焦点を当てる
チームの統合を容易にする – 再利用可能なライブラリを作成して、統合要件を抽象化し、一貫性を確保できるようにします
組織全体に適用できる基準とポリシーを作成する
イベントドリブンアーキテクチャをどのように文書化するかを考えます。

追加のリソース

エンタープライズ統合パターン
- Gregor Hohpe と Bobby Woolf によって書かれた本 Enterprise Integration Patterns では、エンタープライズアプリケーション統合とメッセージ指向ミドルウェアをパターン言語の形式で使用するための 65 のパターンが説明されています。このウェブサイトには、パターンのカタログと他の多くの優れたリソースが含まれています
Amazon EventBridge を使用して、分離されたイベント駆動型アーキテクチャを構築する
- EventBridge の概要、イベント駆動型アーキテクチャの基本、EventBridge 機能の詳細、およびサーバーレスアプリケーションでの EventBridge の最適な使用方法について説明します。
Amazon EventBridge で AWS X-Ray を使用する
- サンプルアプリケーションは、AWS サーバーレスアプリケーションモデル (AWS SAM) を使用して、Amazon EventBridge で AWS X-Ray を使用する方法を示しています
Amazon EventBridge リソースポリシーのサンプル
- Amazon EventBridge リソースポリシー、マルチアカウントデザインパターン、クロスリージョンイベントルーティングのサンプル実装を含む GitHub リポジトリ
Python 用 AWS Lambda Powertools
- AWS X-Ray を使用したトレース、構造化されたログ記録、非同期でのカスタムメトリクスの作成を容易にする AWS Lambda 関数用の一連のユーティリティ。 Powertools は、Python、Java、TypeScript、および .NET で使用できます